IBIS Macromodel Task Group Meeting date: 29 October 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki * Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Walter to send the latest BIRD198 syntax and examples proposal to Bob, Randy, Arpad, and Mike L. - Arpad reported this is done. - Randy to draft a new response to the BIRD198 authors. - Arpad reported this is done. - Ambrish to send the BIRD197.5 proposal to Randy. - Arpad reported BIRD197.5 was introduced in the last Open Forum meeting. - Randy to notify the Open Forum and post BIRD197.5. - Arpad noted BIRD197.5 was posted. - Walter to send out draft 2 of the BCI for Statistical BIRD. - Arpad reported this was done. Walter noted he sent out a draft 3. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 15 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- Enabling Back Channel Interface in statical mode: Walter noted there are three ways to implement statistical iteration between the Tx and Rx. The first is a new AMI_Impulse function. The second method is to use AMI_Init. And, the third is to use AMI_GetWave. Walter stated he did not like to use AMI_GetWave, and others did not like the idea of AMI_Impulse. So, he changed the BIRD draft to use AMI_Init. The change is to the memory handle to act like *AMI_memory that would have already been allocated. We now have a choice to use the BIRD147 AMI_GetWave method, which uses a file set by the BCI_File and uses a file I/O method. He added a new concept, which is to have AMI parameters out that have a special branch for BCI called "(BCI...)". The content of the branch would be defined by the protocol. The EDA tool would take the memory pointer for the Tx and make it the BCI parameter input for the Rx. If the BCI branch is used, the Rx would use the contents of the output from the Tx and ignore the inputs from the AMI parameter input. The EDA tool would not report any of the contents of the BCI branch. Fangyi asked if the first call to AMI_Init is the regular call to the function. Walter stated this is true for both the Tx and Rx. Fangyi asked what is passed to the Tx and what is passed to the Rx, if it is the whole string. Walter stated it is the whole string, as he wanted to make it easier for the EDA tool and not require any parsing on the tool side. The protocol determines the contents of the string. The difference between using this technique is the performance, since file I/O might not be very reliable between multiple tasks. The size of the data may also affect the simulation performance, where file I/O could be significantly slower. Wei-hsing agreed file I/O could be a problem when the file gets closed. Wei-hsing suggested the Tx could become a pass-through, while the Rx is trained initially. He thought you could use the API directly to communicate. The API needs to be known between the Rx and Tx. Ambrish asked if the EDA tool is the best place to mediate between the Tx and Rx. Wei-hsing replied the API would have to be defined between the functions to optimize directly. Ambrish stated you need to now the names of the models. Walter commented there are some tricky things as you need to know the memory handles for the models. Fangyi asked how the Tx DLL would know the location of the Rx DLL once these are already in memory. Wei-hsing stated a file would be written to know the output then use the output from the Tx pass-through and call the Rx model which will talk to its own copy of the Tx. The model makers would need to be careful when using static variables which may be contaminated in this process. There would be two phases to the training. The first phase is when the Tx is a pass-through. Once the data is generated, the Rx can load a proxy of the Tx and do the iterations to write out the training result. When the file exists, the training is done and the normal simulation can be run. Fangyi asked, in Walter's approach, if the AMI parameter out is first allocated by the Rx. Walter replied the Rx will first use the normal branches, then the BCI branch would be allocated. And, this would be used by the Tx. Fangyi commented the Tx would keep its own copy of the memory. Fangyi asked what happens if you have two copies of the Tx and Rx models. He asked how the training configuration files would be used. Wei-hsing replied there would be separate models. Fangyi asked how the proxy models would be named and how to map the proxy models to the real models. Wei-hsing stated, at the end of the training stage, the configuration file is written out and used in the simulation directly. There should be a way to do this. Arpad suggested the DLL_ID could be used for this. Fangyi asked if at the end of the simulation the file would be deleted. Wei-hsing replied, yes. Arpad commented we could still use Walter's idea to communicate without a file. Fangyi stated, in Walter's approach, we do not need to worry about multiple instances. Fangyi asked, since the dummy Tx allocates the memory, who closes the memory. Arpad asked, when the Tx dummy is loaded, how the AMI parameters are loaded by the Rx. Wei-hsing replied there could be many ways to pass in the parameters in separately. Walter commented there are some details to work out for repeaters. Walter noted we would need to make some decisions on the direction whether we want to use file I/O, branches, or come up with another scheme. Walter suggested we should decide a path. He has written up his idea with sufficient detail. The idea of the proxy models is a bit more complicated, since the concept would have to be clear to model makers. Arpad agreed we should make a decision. He agreed Wei-hsing's approach would be more efficient for the EDA tools. Arpad asked if Wei-hsing can write up how this would work. Ambrish asked if this would need any changes to the specification, and he suggested we could have a white paper on this. Wei-hsing will create a slide to show how the pass-through Tx model training approach would work [AR]. Walter noted he would like to see both cases of the Rx train the Tx and the Tx train the Rx. Arpad asked if we should cancel the meeting next week. Walter and Ambrish agreed with canceling the meeting. - Ambrish: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Wei-hsing to create a slide to show how the pass-through Tx model training approach would work. ------------- Next meeting: 12 November 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives